昨天我們成功建立出一個簡單的 Github Actions Workflow，幫助我們上傳 TestPyPI，昨天說會再透過 push 來驗收成果，但其實我們在 Repo 新增 publish.yml 就算是 push 一個新的 commit 進我們的 main branch，所以 Github 有成功執行 我們的 Workflow。我們可以在 Repo 頁看到我們這次執行是否成功，如果是成功會有綠色的勾勾，失敗則是有紅色的叉叉。
沒錯，昨天的結果我們獲得了紅色的叉叉，代表我們其中一個 job 在執行的時候有發生錯誤，可以點圖示進去就能查看是哪個出現問題：
可以看到我們在打包的時候是成功的，但在上傳到 TestPyPI 時卻失敗了，要看更多訊息就需要再點 Details 按鈕，他會帶我們到 Actions 的詳情頁。詳情頁會顯示每個 step 的執行情況，如果有錯誤的 step 會特別 Highlight 起來，方便使用者快速查看：
查看 Log 裡的訊息，最後錯誤訊息是：
HTTPError: 400 Bad Request from https://test.pypi.org/legacy/
File already exists ('baseball_stats_python-0.0.3-py3-none-any.whl',
with blake2_256 hash
'2703e426d8ccbbf20632c2d99047bff0c8cefd0a5c3d0adcb647ca7c2a18f970').
See https://test.pypi.org/help/#file-name-reuse for more information.
他的意思是 TestPyPI 上已經有重複的 0.0.3 版本，所以我們不能上傳上去。在前面的文章我也有提過這個問題（Day 09 - 簡單上傳一版到 TestPyPI），目前是無法直接覆蓋上去，也無法在 TestPyPI 那邊先刪除既有的版本，再重新上傳。可以查看在錯誤訊息裡提供的網頁 https://test.pypi.org/help/#file-name-reuse 。
要解決正個問題，最簡單快速的方法就是去修改 pyproject.toml 裡的 version，我把版本更新成 0.0.3.1 後，Workflow 會再次觸發，然後會發現在原本有叉叉的地方會變成圓點點，代表 Workflow 正在執行，一樣可以點進去看目前執行到哪。
除了直接點擊圖示，我們也可以去上面的 Actions 分頁裡面查看，裡面也會有之前執行過的結果：
可以看到我們改完版本後，也成功獲得綠色勾勾，但這樣表示我們每次更新，都需要手動更新版本，很麻煩，怎麼辦呢？其實在昨天提到的 Publishing package distribution releases using GitHub Actions CI/CD workflows 裡有提供方法，可以使用 if 來設定限制，讓 job 不會每次更新都觸發。文章裡使用的是 if: startsWith(github.ref, 'refs/tags/') ，這一行代表說，只有在上傳 tag 的時候，會執行這個 job。
Tag 簡單的來說是 Github 提供我們一個時間標記，他不會被 commit 的增減影響，就只會存到當下的 commit，通常會用來幫助我們推行版本像是 v1.0.0。Github 還會特別留一頁管理（例如：pybaseball tag 頁）。
他也實在跟 branch 做比較，不過就像剛剛提到的，tag 在存入後不會被 commit 影響而有變動，branch 則是會跟著 commit 有所變動。可以參考這篇文章：【冷知識】標籤跟分支有什麼不一樣？
因為這樣關係，我們可以等告一個段落後，修改我們版號，再建立一個新的 tag 上傳到 Github 後觸發 Actions 就不用每次都改版號了。
如果不想每次手動改版號的話，其實也可以，還記得我們在 Day 09 - 簡單上傳一版到 TestPyPI 裡有提到我們會使用打包工具幫助我們打包，他們各自也都會有提供動態產生版號的方法，像是我們選擇的 Hatchling 有提供 內建 或是使用 Plugin。今天就先不詳細說明，等之後要上傳正式版的時候再來一一介紹。
今天說明如何解決使用 Workflow 上傳重複版號的問題，當初我是沒預料這邊會花那麼多篇幅，自己也是學到了一課。希望有說明的夠完整，明天應該真的能開始設計我們的 Function 了。
一樣最後感謝大家耐心地看完這篇文章，有任何問題與建議歡迎直接留言給我，明天見，晚安。
iThome鐵人賽
看影片追技術